
IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In re Application of: Donoho etal 
Serial No: 09/521 ,805 



Art Unit: 3626 



Docket No.: UN1V0001D6 



Filed: 03/09/2000 



Examiner: Frenel, Vanel 



Title: Relevance Clause For Computer-Relevance Messaging 
January 21, 2004 

Assistant Commissioner for Patents 

P.O. Box 1450 

Alexandria, VA 22313-1450 

Declaration of prior invention to overcome cited patent or publication pursuant to 

37 CFR 1.131 

1 . My name is David S. Hindawi. 

2. I have reviewed the following documents cited by the Examiner as a basis for 
rejecting the herein claimed invention: U.S. Patents to Herz (6,029,195), Basche 
(6,1 19,164), Pant et al (6,012,053) in view of Grasso et al (5,892,909). 

3. The claimed subject matter of my invention is not what is claimed in the above cited 
references. 

4. Herz has a critical reference date pursuant to 37 C.F.R. 1.131 of December 9, 1996 
from Provisional application No. 60/032,461. 



Pant et al has a critical reference date and a filing date of June 23, 1997. 
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Basche has a critical reference date and filing date of April 15, 1997. 

The conception of the claimed subject matter of my invention occurred prior to the 
specified dates of the cited references and was coupled with due diligence from prior to 
said reference date to the filing of the above mentioned application. In support of this, I 
have attached documents, Exhibits A-C below. 

Exhibit A. 

Document Title: "AdviceNet Overview" 
Document Date: November 22, 1996 

This document discloses the present invention including an advice provider which 
broadcasts information over a communications medium to a third party and a reader 
resident with the advice consumer. . 

Exhibit B. 

Document Title: "The AdviceNet System" 
Document Date: January, 26, 1997 

This document discloses a continuing development of the present invention including 
the advice provider and resident reader. 

Exhibit C. 

Document Title: "The AdviceNet Project" 
Document Date: March 11, 1997 

This document discloses a continuing development of the present invention including 
the advice provider and resident reader. 

5. I am the one of the inventors that used each of the attached documents shown in 
Exhibits A-C. Said documents contain a description of the invention. At least one of the 
documents was created on November 22, 1996, showing a conception date of the 
invention prior to the effective date of said references. 
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II 



6. The above-cited application was filed on September. 1, 1998, with U.S. provisional 
No. 60/098,798. 



7. The above supporting facts show the conception of the invention prior to the 
effective date of said reference coupled with due diligence from prior to said date to the 
filing of the above-cited application. 

8. I herein acknowledge that willful false statements and the like are punishable by fine 
or imprisonment, or both (18 U.S.C. 1001) and may jeopardize the validity of my 
application or any patent issuing thereon. All statements made of my own knowledge 
are true and all state/nents made on information or belief are believed to be true. 





David S. Hindawi, 



Date 



Declarant 
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EXHITIT A 



RECEIVED 

f£B04 zoo^ 

GROUP 3600 

AdviceNet Overview 

Friday, November 22, 1996 



Introduction 

Computer reliability is like the weather: everybody talks about it, but nobody seems 
to do anything about it. The reason, perhaps, is that while we sometimes perceive 
reliability as a s single issue, problems with reliability come from a great many 
sources, and have an enormous variety of solutions. 

In fact, many individual reliability problems have been solved, and more solutions 
are found each day. Hardware vendors replace faulty parts; software authors revise 
their work; and users themselves experiment with their machines to find ways to 
keep them working. 

Therefore, we propose to attack the problem of reliability from a different angle — 
we will treat it not as a software-and-hardware problem, but as a communication 
problem. Rather than solving problems ourselves, we will provide a way to deliver 
solutions to the people who need them. 

The State of the Art 

We are not the first to tackle this communication problem. Most users communicate 
their solutions informally; many reach a wider audience through user groups and 
bulletin boards; some sell their advice in newsletters or magazine columns. 
Technical support workers are paid in part to distribute such advice; system 




administrators are paid in part to collect and sift through the advice others have 
made available. 

But these existing pathways of communication have weaknesses we think we can 
improve upon. Informal communication reaches a limited audience; information is 
often corrupted as it spreads in this way. User groups, bulletin boards, newsletters, 
and advice columns require attention even when their advice is not pertinent. 
Technical support workers are expensive, and have no effective way to broadcast 
their advice to those who need it. System administrators are even more expensive, 
and have limited capacity to remember solutions to rare problems. 

Our Solution 

We propose to create an automated system which uses the internet to distribute 
advice. Our plan is to build software which establishes a subscription-based, point- 
to-point network which will deliver signed advice to users in a mixed machine- and 
human-readable format. 

We envision a subscription-based system because we see the relation between an 
advisor and an end user as an ongoing one. Advisors not only create fresh advice 
from time to time, but also update and correct their previous advice. We want users 
to receive these updates with as little effort as possible. 

We envision a point-to-point network because there are so many sources of advice 
that collecting it all would be a monumental task, and because these are so many 
users that distributing it all would be still more difficult. A point-to-point network 
distributes this work over many machines on the internet. Further, it gives us a 
first layer of screening and security: users will (we hope) not subscribe to advice 
sources which they find irrelevant or untrustworthy. Finally, it allows for privacy: 
advice can be provided on a part of the internet which is not globally accessible. 

We will provide a second layer of security by insisting that advice be signed. The 
principal defense a user has against bad advice is knowledge of the source: advice 
from a trusted source is usually good advice. We will build upon that trust by 
making sure the source is known, and verifying the source cryptographically. 



We want at least some portions of the advice to be machine-readable because we 
want to automatically filter advice for relevancy. We imagine that most advice will 
concern particular hardware or software configurations, and that most advice will 
be irrelevant to most users. A significant part of the value we can provide is in 
locating that portion of the available advice which is relevant. In the ideal situation, 
the actions advised will also be machine-executable, so that the user will only be 
called upon to accept or reject the advice. 

On the other hand, we realize that neither the conditions under which advice 
applies nor the advised actions can always be handled exclusively by the computer; 
even if they could, a user should have the chance to understand the advice before 
accepting or rejecting it. Therefore it is essential that advice be provided in a 
human-readable format. 



Delivery 

We intend to use HTTP as the primary delivery mechanism for advice. Each user 
will have a list of URIs to be searched for advice; a demon on the user's machine 
will periodically check those locations for new advice or updates to old advice. The 
URI will point to a table of available advice, which will contain the URIs and dates 
for advice files and other advice tables. This nested approach should allow for a 
relatively small transaction when small changes are made by an advice supplier. 

While the user ought to be able to subscribe to an advice site by typing in its URI, 
we imagine that the subscription will more typically be created by an internet 
helper program which interprets the URI by adding it to the subscription list. This 
will make it easy to advertise advice sites on the web or by email, Also, we will want 
to provide a mechanism by which a program's installer could subscribe the user to 
the program's official advice site. 

We imagine that the delivery demon collects advice and deposits it in a database on 
the user's machine (perhaps the same demon could be used to make a mirror of 
advice sites?) In doing so, it should probably make a judgment as to the possible 
pertinence of the advice — there's no reason for a user's machine to download or 
remember advice about products the user doesn't own. But advice about things 
which work now but could fail later should be kept. 



Finally, we imagine that users could also get advice from themselves. After putting 
together a working system, a user could take a snapshot of it — creating an advice 
database which can locate, if not repair, changes made to the system by by accident. 
Of course, since users are unlikely to put in the effort to create and keep up to date 
an entirely reliable advice database, they should take advice from themselves with 
a grain of salt. 

Checking 

We imagine a second demon running on the user's machine, which compares the 
state of the machine to the the advice database. When the conditions attached to a 
piece of advice are fulfilled, it reports that advice to the user. 

The heart of this comparison seems to be a sort of outline-based pattern matching. 
We imagine that a system can be described as an outline: it has various pieces of 
hardware and software packages; the packages have folders and files; the devices, 
folders, and files have various attributes. Advice will come with patterns attached to 
it; when the system's outline matches the pattern, the advice is relevant. 

While the description above covers the intended result, it's probably not the 
algorithm we want to use. For efficiency we'll want to only generate those parts of 
the system description which play a part in the pattern matching. 

If done in a sufficiently general fashion, we should be able to build other 
applications on this same core. One which we have imagined is the composition of a 
personalized newspaper from a set of rules describing a reader's interests. 

Reporting 

When a piece of advice becomes relevant, we'll prepare a report for the user, 
containing, or at least summarizing, all of the relevant advice. Our current feeling 
is that the report will be built from passages of HTML found in the advice, and 
presented through a web browser. In this way, we get not only a way to include 
formatted text and pictures, but also links may be embedded which a user can 
follow for more complete information. 



The advice reports may also contain forms, which the user can use to accept 
machine-executable advice. In some cases, this will require only pressing a button; 
in others, a more complex form could be presented. 

We can create a more flexible reporting mechanism by using a compound-document 
format such as OpenDoc. This would allow pieces of advice to present richer user 
interfaces, and may improve communication between our programs and the advice 
user interfaces. 

Taking Action 

While the only action necessary in response to some advice is to inform the user, in 
other cases we imagine that a full response could be available to the user at the 
click of a button. A web browser acting alone will not make the changes to a user's 
system which we imagine we'll want, but it is possible that by including a helper 
program (whose communication with the web browser is secure against off-machine 
spoofing) we can take more dangerous action, such as downloading and executing a 
program which will fix a problem. 

We expect to include utilities which will, at a minimum, execute the advice users 
can generate automatically; we may also include utilities for tasks we expect to be 
advised by third parties, such as upgrading software. 




EXHIBIT B 



f £B 0 4 V» 

GROUP 3* 




The AdviceNet System 



Sunday, January 26] 1997 



The Subscription Editor 

I'm thinking we should store each advice subscription as a separate document, 
which would contain at least these parts: 

□ the site's URL 

□ the site's title 

□ a short description of the site 

□ the site's recommended update frequency 

□ the user's chosen update frequency 

We'll need a small application which displays this information, allows the 
frequency to be edited, and can trigger an immediate update. It should probably 
have an "Update All" switch as well. 

This would also be the application to use to create a new subscription by hand, and it 
should be tied in to Internet Config so that it can display advice sites when other 
programs find them on the net. 

Perhaps this application should be able to make some changes to the advice database 
as well, such as purging advice from a particular site or adding new advice from files 
on the local file system. 

The Subscription Demon 

This demon (which may be in the same background application as the information 
demon) watches for the subscription list to change or for subscriptions to get out of 
date. When they do, it tells the advice gatherer to update the advice from the 
subscription's URL. 



The Advice Gatherer 



This part goes to the network in response to requests from the subscription editor 
("Update Now"), the subscription demon (as subscriptions go out of date), or the 
information demon (as pieces of advice recommend gathering others). It downloads 
pieces of advice from the net, parses them, and links their guards into the 
information network. 

Ideally the gatherer would have the usual array of internet protocols at its disposal, 
but I don't see any reason why HTTP, SHTTP, and local file system access wouldn't 
suffice. 

The Fact Checkers 

These parts are called upon by advice guards to examine the state of the system. Each 
will know how to extract some piece of information from the system, and will have 
mechanisms for reviewing that information. We should have a plug-in system for 
these pieces, so that people can check for information we haven't yet imagined. But 
we should also include some standard kinds of information: 

□ devices 

□ computer & CPU model 

□ amount of RAM 

□ directory and file info 

□ system components: applications, control panels, fonts, etc. 

□ version numbers 

□ gestalt values 

□ advice subscriptions 

□ advice stored in the system 

□ advice which has been triggered 

The Information Network 

The information network builds complex facts out of the simple facts and 
relationships described by the fact checkers. Each node of the network will represent 
some fact about the system, and links between the nodes will carry updates to the 
information. When the advice gatherer collects a piece of advice, the guard on that 
advice will be linked into the network, along with any lesser conditions it depends 
upon. To keep the network efficient, different guards will be able to share nodes in 
the network — there may be hundreds of pieces of advice which refer to the system 
version number, but the version number will have only one node in the network. 



The Information Demon 



This demon scans the information network, watching for conditions which have 
changed and updating the facts related to them, When it finds that a guard 
condition is satisfied, it may ask the gatherer for more advice, or launch the display 
application to display advice to the user. (Before displaying advice, it should 
probably flush the information network for more advice that has become pertinent.) 

The Display Application 

The display application is launched by the information demon when a piece of 
advice becomes pertinent. It will display the advice's message (presumably in 
HTML, but we ought to support some other MIME types) and the associated 
signature. 

It will also provide an extension — presumably a new form submission method — 
which can trigger effects not usually available to HTML. We want advice, once 
accepted, to be able to download and execute an arbitrary native application. 

The HTML will usually contain the URLs and checksum of an application to run, 
and of files to be handed to that application as input. In addition, the application 
will receive the form result, if any. Through this mechanism and the use of hidden 
fields the effect application can also get information on how the advice was 
triggered. 

In addition to the options the advice offers to the user, the display application 
should provide some standard options. When the user sees a piece of advice, he 
should always be able to postpone it, ignore it, have the system forget it, check for 
updates to it, or cancel his subscription to the site it came from. 

Finally, the display application should be able to display and check the digital 
signatures on advice. 

The Effects 

Once accepted, advice acts on the system by launching applications. Any application 
could be launched as the effect of a piece of advice, but I imagine that some small 
applications will be written specifically for advice, and thus take advantage of 
information about the advice which we make available to them. These applications 
can be written in either a traditional programming language or in any general- 
purpose scripting language available on the target system. 

While a piece of advice can download its effect application from the net, it's best if 
the applications for executing some common kinds of advice are available locally. 
The only three kinds of applications I've thought of that we need are downloading 
files to install, locating misplaced files, and changing advice subscriptions. 



Central Advice Databases 

There are a few kinds of advice we should probably provide ourselves, either as part 
of the bootstrapping process or as a service to enhance the usability of AdviceNet: 

• Site Announcements, which would contain advice like "If you have 
MacWrite, you may want to subscribe to the Claris advice site." 

• Urgent Updates, containing advice like "If you subscribe to the Claris site, and 
you downloaded advice from it yesterday, you should check it again 
immediately, because they told us they published something really stupid. 

• The Better Advice Bureau, which gives advice like "If you subscribe to 
EvilCorp, you should know that we get lots of complaints about the advice 
they give out. We think you should stop your subscription and purge their 
advice from your system." 

Automated Advice Writers 

Some kinds of advice can be so detailed that it's much easier to extract the right 
advice from a working machine than it is to write it by hand. In particular, a 
thorough check of a complicated software installation may be difficult to write by 
hand. Also, some kinds of advice, such as a check of the system and hardware 
requirements for a piece of software, could be written just by filling out a form. So 
we should write a few applications which produce advice by examining part of an 
example machine, or by questioning the advice author. The output can then be 
tweaked into the advice the user needs. 

Direct Advice Installation 

We'd like to provide a mechanism for a software installer to directly add advice to 
the database. That way the big lump of advice that comes with a new software 
package won't require a lengthy download. 
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Introduction 



Computer reliability is like the weather: everybody talks about it, but nobody seems 
to do anything about it. The reason, perhaps, is that while we sometimes perceive 
reliability as a s single issue, problems with reliability come from a great many 
sources, and have an enormous variety of solutions. 

In fact, many individual reliability problems have been solved, and more solutions 
are found each day. Hardware vendors replace faulty parts; software authors 
revise their work; and users themselves experiment with their machines to find 
ways to keep them working. 

Therefore, we propose to attack the problem of reliability from a different angle — 
we will treat it not as a software-and-hardware problem, but as a communication 
problem. Rather than solving problems ourselves, we will provide a way to deliver 
solutions to the people who need them. 



user groups and bulletin boards; some sell their advice in newsletters or 
magazine columns. Technical support workers are paid in part to distribute such 
advice; system administrators are paid in part to collect and sift through the 
advice others have made available. 




But these existing pathways of communication have weaknesses we think we can 
improve upon. Informal communication reaches a limited audience; information 
is often corrupted as it spreads in this way. User groups, bulletin boards, 
newsletters, and advice columns require attention even when their advice is not 
pertinent. Technical support workers are expensive, and have no effective way to 
broadcast their advice to those who need it. System administrators are even more 
expensive, and have limited capacity to remember solutions to rare problems. 

Our Solution 

We propose to create an automated system which uses the internet to distribute 
advice. Our plan is to build software which establishes a subscription-based, 
point-to-point network which will deliver signed advice to users in a mixed 
machine- and human-readable format. 

We envision a subscription-based system because we see the relation between an 
advisor and an end user as an ongoing one. Advisors not only create fresh advice 
from time to time, but also update and correct their previous advice. We want 
users to receive these updates with as little effort as possible. 

We envision a point-to-point network because there are so many sources of advice 
that collecting it all would be a monumental task, and because these are so many 
users that distributing it all would be still more difficult. A point-to-point network 
distributes this work over many machines on the internet. Further, it gives us a 
first layer of screening and security: users will (we hope) not subscribe to advice 
sources which they find irrelevant or untrustworthy. Finally, it allows for 
privacy: advice can be provided on a part of the internet which is not globally 
accessible. 

We will provide a second layer of security by insisting that advice be signed. The 
principal defense a user has against bad advice is knowledge of the source: advice 
from a trusted source is usually good advice. We will build upon that trust by 
making sure the source is known, and verifying the source cryptographically. 



We want at least some portions of the advice to be machine-readable because we 



want to automatically filter advice for relevancy. We imagine that most advice will 
concern particular hardware or software configurations, and that most advice 
will be irrelevant to most users. A significant part of the value we can provide is 
in locating that portion of the available advice which is relevant. In the ideal 
situation, the actions advised will also be machine-executable, so that the user 
will only be called upon to accept or reject the advice. 

On the other hand, we realize that neither the conditions under which advice 
applies nor the advised actions can always be handled exclusively by the 
computer; even if they could, a user should have the chance to understand the 
advice before accepting or rejecting it. Therefore it is essential that advice be 
provided in a human-readable format. 

Delivery 

We intend to use HTTP as the primary delivery mechanism for advice. Each user 
will have a list of URIs to be searched for advice; the user's machine will 
periodically check those locations for new advice or updates to old advice. The URI 
will point to a table of available advice, which will contain the URIs and dates for 
advice files and other advice tables. This nested approach should allow for a 
relatively small transaction when small changes are made by an advice supplier. 

While the user ought to be able to subscribe to an advice site by typing in its URI, 
we imagine that the subscription will more typically be created by an internet 
helper program which interprets the URI by adding it to the subscription list. 
This will make it easy to advertise advice sites on the web, by email, or through 
other advice sites. Also, we will want to provide a mechanism by which a 
program's installer could subscribe the user to the program's official advice site. 

We imagine that the program will collect advice and deposit it in a database on the 
user's machine. In doing so, it may make a judgment as to the eventual 
pertinence of the advice — there's no reason for a user's machine to download or 
remember advice about products the user doesn't own. But advice about things 
which work now but could fail later should be kept. 



Checking 

Some advice which is not relevant when it is first loaded into the machine may 
become relevant with the passage of time. In particular, advice which describes a 
properly-installed piece of software may be triggered when a file is moved or 
modified. To handle this possibility, the program will need to continually compare 
the state of the machine to the advice in the database. When the conditions 
attached to a piece of advice are fulfilled, it will report that advice to the user. 

The heart of this comparison seems to be a sort of outline-based pattern matching. 
We imagine that a system can be described as an outline: it has various pieces of 
hardware and software packages; the packages have folders and files; the devices, 
folders, and files have various attributes. Advice will come with patterns attached 
to it; when the system's outline matches the pattern, the advice is relevant. 

While the description above covers the intended result, it's not the algorithm we 
want to use. For efficiency we'll only generate those parts of the system 
description which play a part in the pattern matching. 

Reporting 

When a piece of advice becomes relevant, we'll prepare a report for the user, 
containing, or at least summarizing, all of the relevant advice. Our current 
feeling is that the report will be built from passages of MIME content such as text 
or HTML, and presented in a manner similar to email, giving the user an "inbox" 
of relevant advice. We'll allow advice authors to categorize advice, which will then 
be sorted automatically into folders within the inbox. 

To simplify the presentation of solutions to problems, we will allow advisories to be 
adorned with buttons which trigger scripts written in some system-specific 
scripting language. Advisories written in HTML may contain links to web pages 
and forms, allowing the user to engage in an online dialog with a web server. We 
may also want to allow advisories to present a more complicated user interface 
written in Java. 



Taking Action 

While the only action necessary in response to some advice is to instruct the user, 
in other cases we imagine that a full response could be available to the user at the 
click of a button. We want to provide advice authors the ability to execute scripts in 
the system's native scripting language, and to download and execute programs 
available on the net. 

In addition, we expect to include utilities which will handle common advice 
actions, and won't have to be downloaded from the net. These actions include 
locating and updating files, changing advice subscriptions, and purging advice 
files from the user's database. 



Examples 



To solidify the way the system works, we'll follow several pieces of advice from the 
author through their eventual resolution. We'll start with a very basic piece of 
advice: some printers have been shipped with a defective part, and the user can 
ask for a replacement. 

This advice follows a simple path from the author to the user: 



Author 



(^Packager 




Web Server^) 




(^Gatherer 



To start the process, the author writes the advice, using a program we'll supply 
which will have a user interface similar to an email editor. Here's what the 
author will write: 



Subject: Some LaserWriter IINT Printers are defective 

Guard: exists printer where (model of it is "LaserWriter IINT") 

Display-Path: Printer 



LaserWriter IINT Printers with serial numbers between 123 and 456 
are defective. Call (800)123-4567 for a replacement part. 



The guard line describes a condition which must be met before this piece of advice 
will be considered relevant: in this case, there must be a LaserWriter IINT 
printer available to the system. The display-path line categorizes this advice, 
putting it into the folder "Printer" folder within the advice inbox. 

The advice editor packages this advice by adding lines to the header: 

From: user@host.com (The author) 

Date: Tue, Mar 4, 1997 12:30 PST -0800 

Subject: Some LaserWriter IINT Printers are defective 

Guard: exists printer where (model of it is "LaserWriter IINT") 

Display-Path: Printer 

Signed: 89579857946965897893274986526589 

MIME-Content-Type: TEXT/ASCII 

MIME-Content- Length: 87 

LaserWriter IINT Printers with serial numbers between 123 and 456 
are defective. Call (800)123-4567 for a replacement part. 

The only interesting line added here is the signature line. We want to encourage 
advice authors to digitally sign their advice, so that users will have greater 
confidence in the advice they receive. 

Next, the author makes the advice available, by placing it in on a web site to which 
owners of these printers are expected to subscribe. In this case, an advice site 
would presumably be maintained by the company selling printers, and users 
would have either had a subscription installed with their printer software, or 
have found the advice subscription through the internet. 

The user's machine, during a routine check for advice updates, will notice this 
advisory and download it. In the process, it will add a line indicating the source 
and time of arrival of the advice: 

Received: from http://www.apple.com/PrinterAdvice.adv 
by localHost (123.234.123.234); 
Mon, Mar 10, 1997 14:30:16 PST -0800 

Upon receipt, the advice is checked for relevance; that is, the guard lines on the 



advisory are tested. If all the guard lines can be evaluated and are satisfied, the 
advisory will be listed in the display application. If not, it will be filed and 
rechecked periodically until it expires. 

The advisory will wait in the user's advice inbox, filed under its display path 
"Printer" until either the user opens it or it becomes irrelevant. Eventually, the 
user will read it, decide how to respond to the advice, and throw it away. 

The preceding example is of the simplest kind of advice, a plain text message. 
Now we'll move on to some more complicated pieces of advice. 

Our next example is of a free minor update to an application. This piece of advice 
has two guard lines, both of which must be satisfied before the advice is 
considered relevant. It also suggests a response: an updater program is available 
on the web. 

Subject: A new version of MicroPhone is available 
Guard: version of application id 'DFBO' >= version "4.0" 
Guard: version of application id 'DFBO 1 < version "4.0.3" 
Display-Path: Microphone 
Button: "Install" 

Script: tell application "Downloader" to run 

" http : //www . svcdudes . com/Mi c roPhone/updates/Mi c roPhone 4.0.3" 
MIME-Content-Type: TEXT/ASCII 
MIME-Content- Length: 59 

Version 4.0.3 of Microphone is now available. It fixes several 
bugs, including blah, blah, and blah. You may upgrade to this new 
version for free. 

When the display application shows this advice, it will put a button named 
"Install" next to the text of the message. If the user clicks this button, the script 
will run, downloading the updater and running it. The downloader application is 
one of the simple applications we will provide for executing standard kinds of 
advice. 

Sometimes there's more than one way to respond to an advisory. An advice writer 
can include more than one MIME section in a single advisory to produce a list of 



responses. Each section can have its own button and script; when the user 
chooses a button, the script is executed. 

In this example, a file associated to the application has been deleted or moved 
from its proper location. Three options are presented: search for the file on local 
disks; download a replacement from the internet; or reinstall the file from the 
application disks. 

Subject: MPToolbox is Missing 

Guard: version of application id 'DFBO' >= version "3.0" 
Guard: ! exists file "MPToolbox" 

of parent directory of application id 'DFBO' 
Display-Path: MicroPhone 
MIME -Content-Type: TEXT/ASCII 
MIME-Content-Length: 87 

The file "MPToolbox" is not in the MicroPhone folder. Without it, 
some MicroPhone scripts will not operate correctly. 

Button: "Search" 

Script: tell application "Searcher" to launch 
MIME -Content-Type: TEXT/ASCII 
MIME-Content-Length: 87 

The file may have been moved to another place on the disk. If so, 
the problem can be solved by moving it back to the MicroPhone 
folder. 

Button: "Download" 

Script: tell application "Downloader" to 

copy from "http://www.svcdudes.com/MicroPhone/files/MPToolbox" 

to parent directory of application id 'DFB0' 
MIME -Content-Type: TEXT/ASCII 
MIME-Content-Length: 87 

You can solve this problem by downloading "MPToolbox" from the 
Software Ventures web site. 



Button: "Reinstall" 



Script: tell application "Finder" to 

open alias "MP Install 1: Install MicroPhone" 
MIME-Content-Type: TEXT/ASCII 
MIME-Content-Length: 87 

This problem can be solved by reinstalling MicroPhone from disks. 

While the advisory's window is open, the display application will closely watch the 
guard on the advisory; if the problem is fixed, the advisory will become irrelevant 
and the window will be closed. If the problem is not fixed, the user can choose 
another option. 

Sometimes there are responses which are only appropriate to some users having 
a problem. Therefore, we will allow guards to be placed on sections of an advisory. 
Those sections will be shown only to users whose machines satisfy the guards. 

In this example, an application has been modified; the advice detects the 
modification by using a checksum. The problem can be solved by reinstalling the 
program, but if the user has the virus checking application Disinfectant, the 
advisory suggests checking the application for viruses. 

Subject: MicroPhone has been altered or damaged 

Guard: version of application id 'DFBO' = version "4.0.2" 

Guard: checksum of application id 'DFBO' != "AB76E48CF09B533F" 

Display-Path: MicroPhone 

MIME-Content-Type: TEXT/ASCII 

MIME-Content-Length: 59 

The application "MicroPhone" has been altered or damaged. 

Guard: exists application id 'D2CT' 

Button: "Disinfect" 

Script: tell application id ' D2CT ' 

to open application id 'DFB0' 
MIME-Content-Type: TEXT/ASCII 
MIME-Content-Length: 80 

This problem may have been caused by a computer virus. You can 
check for known computer viruses by running "Disinfectant." 



Button: "Reinstall" 

Script: tell application "Finder" to 

open alias "MP Install 1: Install MicroPhone" 
MIME-Content-Type: TEXT/ASCII 
MIME-Content-Length: 87 

This problem can be solved by reinstalling MicroPhone from the 
original disks. 

In this case, the first response is unlikely to solve the problem, and is not 
presented as a solution, but just as a suggestion. As before, the advisory window 
will stay open until the user dismisses it or the problem is fixed. 

Sometimes, a plain text interface is insufficient to convey the content of an 
advisory, or a simple button is not enough of a user interface to provide a proper 
response to the advice. For these cases, we will offer HTML as an alternative to 
plain text. In the example below, an HTML form allows a user to order an 
upgrade to an application over the web. For those users who don't care to order 
over the web, a phone number is provided; if the computer can dial the phone, it 
offers to dial that number. 

Subject: A new version of MicroPhone is available 
Guard: version of application id 'DFBO' < version "4.0" 
Display-Path: MicroPhone 
MIME-Content-Type: TEXT/HTML 
MIME-Content-Length: 276 

<html> 

Version 4.0.3 of MicroPhone is now available. This new version 
has cool features and is fully buzzword-enabled. You can upgrade 
to this new version for a tidy sum.<p> 
<form method=post 

url="shttp://www.svcdudes.com/cgi-bin/upgrade.cgi"> 
Credit card: 

<select name="CardType"> 

<option>American Express</option> 
<option>Di scover</option> 
<option>Mastercard</option> 



<opt i on>Vi sa</opt i on> 
</selectxbr> 

Number: <input type=text name="CardNumber"xbr> 
Expiration date: <input type=text name="Expiration"xbr> 
<input type=submit name="Purchase"> 
</form></bodyx/html> 

Guard: exists extension "Telephony" 
Button: "Dial" 

Script: tell application "PhoneDialer" to call " (800)734-6727" 
MIME-Content-Type: TEXT/ASCII 
MIME-Content-Length: 87 

You can also order Microphone by phone at (800)734-6727. 

Guard: ! exists extension "Telephony" 
MIME-Content-Type: TEXT/ASCII 
MIME-Content- Length : 87 

You can also order Microphone by phone at (800)734-6727. 

Our final example doesn't show off any further features of the system, but rather 
demonstrates that this system can be used in conjunction with a program's 
existing error-checking mechanisms to get users with problems in touch with 
technical support. In this example, a piece of advice looks for an error log, and 
suggests that the user deliver the log to the maintainers of the program: 

Subject: MicroPhone reports unexpected errors 

Display-Path: MicroPhone 

Guard: exists file "MicroPhone Error Log" 

of parent directory of application id 'DFBO' 
Button: "Send Report" 

Script: tell application "Uploader" to submit 

file "MicroPhone Error Log" 

of parent directory of application id 'DFBO' 

to " http : //www . svcdudes . com/cgi -bin/bugReporter . cgi " 
MIME-Content-Type: TEXT/ASCII 
MIME-Content-Length: 59 



MicroPhone has encountered problems which were not fully 
anticipated by the programmers. The program has compiled a report 
of these problems. To help them fix these problems, please send 
this report to Software Ventures. 

Guard: size of file "MicroPhone Error Log" 

of parent directory of application id 'DFBO' > 100000 
Button: "Delete" 

Script: tell application "Finder" to move 

file "MicroPhone Error Log" to the trash folder 
MIME-Content-Type: TEXT/ASCII 
MIME-Content-Length: 59 

The reports of Microphone's problems have grown to more than 
100K. If you do not wish to send these reports to Software 
Ventures, you may throw them away. 



The Central Parts 

The basic path advice takes from its author to its recipient passes through five 
major pieces of software, four of which we'll write: 




(^Package 



Web Server^) 

The Internet 

^Gatherer 




Checker 




Display^) 



User 



In the examples above, we've seen how these parts work together to deliver advice 
to the user. In the descriptions below, we'll see in more detail how the parts 
themselves will work. The descriptions are arranged in the order I expect they 
should be written, working away from the user. 



The Display Application 

The display application is where the user interacts with advice. Its main interface 
is similar to an email reader, presenting a list of advisories arranged by subject, 
date of reception, or date of relevancy. The user will have two three-way choices 



for filtering the advice. The display can be set to show read, unread or both read 
and unread advisories, and can independently be set to show relevant, irrelevant, 
or both relevant and irrelevant advisories; the default will be to display all relevant 
advisories. The advisories will be further sorted by their display paths, producing 
a built-in hierarchy of folders. 

The display application will also be able to open advice files directly, rather than 
as part of the subscription and system-monitoring mechanism. When the user 
opens an advice file directly, it will be displayed in a separate window from the 
inbox, but in other respects it will operate similarly. 

When an advisory is opened, its signature and contents will be shown, including 
any buttons associated to its sections. When the application is set to show 
irrelevant advice, those sections which are irrelevant will be distinguished 
visually, and their buttons will be disabled. 

While the display application is running, it will check continually for relevant 
advice becoming irrelevant. As it notices these changes, it will remove the advice 
from the list (if irrelevant advice is not being shown) and will close any displaying 
the advisory. 

The display application will also allow the user to add or remove advice from the 
system, check for updates, or to change advice subscriptions. In particular, when 
viewing an advisory, the user should be able to directly throw it away, check it for 
updates, or cancel the subscription which brought it. 

The display application is probably the most complicated part of the advice system; 
even apart from the need to include an HTML display engine, it may take three 
months or more to have all of its basic functionality in place. 

The Advice Checker 

The advice checker's job is to keep track of which advice is relevant and which 
advice is irrelevant. It isn't so much an application as a module used by the 
display application to evaluate guards and (depending on the updating model we 
choose) by a demon which updates the values of the guards when the display 



application isn't open. 

The difficulty of writing the advice checker is connected to the guard language. I 
expect we could use AppleScript as a guard language for prototype purposes, and 
have the checker working in a matter of a few weeks. However, AppleScript 
probably won't suffice for a shipping version; using it in guards seems to present 
too many security problems. Putting together a checker with a full language 
interpreter could take two to four months. 

Associated with the checker is a mechanism for extracting basic facts from the 
system; in some sense, these basic relationships give a vocabulary to go with the 
advice checker's grammar. We'll want to have a plug-in interface to the basic 
facts, which will take about two weeks to produce; in addition we'll want to 
provide some basic facts, including; 

□ devices 

□ computer & CPU model 

□ amount of RAM 

□ directory and file info 

□ system components: applications, control panels, fonts, etc. 

□ version numbers 

□ gestalt values 

□ advice subscriptions 

□ advice stored in the system 

□ advice which has been triggered 

The individual checkers will be simple, with most taking less than a day to 
produce. 

The Advice Gatherer 

This is the part which which will download advice from the net. Its heart will be 
an implementation of HTTP and SHTTP. I imagine that the HTTP can be up and 
running in about two month's work; while I'm less familiar with SHTTP, I 
suspect it will take less than one month more. 



The Advice Packager 

The packager is the basic authoring tool; it will work much like an email editor 
combined with the advice display application. (It may even be appropriate to sell 
the packager as an enhanced version of the client program, as with Netscape.) 
The basic interface is a text editor with separate fields for the header lines which 
the author can fill in. When the advice has been written, the packager fills in the 
computer-generated header lines. 

In its basic form, the packager is a simple application, and should take less than 
a month to write. If we expand its definition to include editing HTML, it becomes 
a much more lengthy project. 



The Peripheral Parts 



While the parts above form the core of the advice system, there are several other 
parts we want to add to give the system a richer flavor. 



Automated 
Writers 



Author 



Packager 




Central 
Databases 



Web Server^) 



(^Gatherer 



Software 
Installers 



Standard 
Effects 




Subscription 
Editor 



Subscription Editor 

The subscription editor is the interface through which the user can add and 
remove subscriptions. For each site the user subscribes to, the subscription editor 
will keep track of 



□ the site's URL 



